軟體開發的流程中，有些時候，同樣的內容因應開發階段的不同，可能需要在不同的系統上執行，如軟體的部署，在開發階段可能需要部署到開發(Develop)環境，在正式上線，則部署到正式環境(Production)，對於部署的過程，其不一樣的，可能只在於主機位址、帳號、密碼等等資訊不同，但流程及方法是一樣的。

GitLab CI 提供了各個層級的變數設定，但，提供給部署環境的帳號密碼的具機密性的變數該怎麼管理？又不同的環境但相同的變數在使用時，該怎麼使用？

一、GitLab 環境 environment 設定

在 GitLab 上，提供了所謂的環境 (environment) 的設定，其就可以解決當不同環境，定義相同變數的問題。該在什麼位置新增與修改環境呢？GitLab 的環境新增修改主要置放於 「Operations -> Environments」裡頭。

可以透過「New environment」綠色按鈕進行新增。新增環境僅需要填入環境名稱及其可用的 URL。

在建立好環境後，也可以透過環境查看該環境執行過的 GitLab CI 工作，其部分工作資訊。

二、設定環境對應的變數

設定好環境之後，在專案階層的「settings -> CI/CD -> Variables」中，點選「Expand」後，即可看到目前的專案層級變數。

在新增或編輯變數時，清除 「Environment」上的 All (default)就可以看到在上一章節所設定的環境，如 Develop、Production。

三、在 GitLab CI 中如何使用環境？使用 environment 指定環境

在 .gitlab-ci.yml 中，只需要在工作中透過 environment 指定環境名稱，則該工作在執行過程使用的變數即是在 CI/CD 中設定指定環境的變數。如下範例：

.build-template:
  stage: build
  script:
    - echo "${ENV_ACCOUNT}"
    - echo "${ENV_HOST}"

build-on-delop:
  extends: .build-template
  environment: Develop

build-on-production:
  extends: .build-template
  environment: Production

目前在專案環境變數上先設定 ENV_ACCOUNT 及 ENV_HOST 兩個變數其在 Develop 及 Production 上都是不同的數值。在執行後：

如下圖在 Develop 的環境上，輸出的內容為對應的數值：

同樣的在 Production 的環境上，也可以正確取得原定設定在 Production 的數值：

在 Operations 裡頭的 Environment 也可以馬上看到上述執行的紀錄。

四、檔案形式的變數 File Type Variable

在部署環境上，有時候需要連接到其他主機，會使用到如 SSH Key 來進行連接或檔案形式的檔案做部署動作，而，在設定變數的時候，即可選擇將如 SSH Key 這樣的變數設定為檔案形式，如此可以減少一次在工作中還需要先把變數存入到檔案的動作。

首先在變數設置的位置建立 File Type 的變數 ENV_KEY，接著查看底下的例子：

.build-template:
  stage: build
  script:
    - echo "${ENV_KEY}"
    - cat "${ENV_KEY}"

build-on-delop:
  extends: .build-template
  environment: Develop

build-on-production:
  extends: .build-template
  environment: Production

接著查看 Production 的執行結果：

如上圖，當在 script 中，其顯示出來的是一個檔案路徑，必須要透過查看指令 cat 才能看到檔案的內容。FileType 的變數，可以方便在做如 SSH 連接主機值，直接以參數指定檔案位置方式使用，如官方手冊上的範例，原本 KUBE_CA_PEM 變數是變數型態，其需要轉存入檔案中，才能供指令使用：

echo "$KUBE_CA_PEM" > "$(pwd)/kube.ca.pem"
kubectl config set-cluster e2e --server="$KUBE_URL" --certificate-authority="$(pwd)/kube.ca.pem"

但將變數型態改為 File 後，可以直接使用：

kubectl config set-cluster e2e --server="$KUBE_URL" --certificate-authority="$KUBE_CA_PEM"

五、變數的使用範圍 protected

有部分的變數只希望在限定的環境下使用，如部署到正式環境的帳號密碼等變數，就會希望他只能在限定的分支上被使用，如 master 或有上限定 Tag 的 Git Commit。

這個需求在設定變數的時候也是可以完成的。如下圖，在編輯變數的地方，可以選擇是否 「protect variable」，當勾選後，這個變數就只能在限定的分支或限定的 Git Tag 上使用。

使用上的情境如下簡單範例：

build-on-production:
  stage: build
  script:
    - echo "${ENV_ACCOUNT}"
  environment: Production

同樣的 GitLab CI 工作，一則在新建立的 Develop 分支上執行，另一則在系統預設為 protect 的 master 分支執行，如下圖，在 master 分支執行的畫面，變數 ENV_ACCOUNT 可以順利的呈現。

如下圖，在 develop 分支執行的變數，因為無法取得變數 ENV_ACCOUNT，所以畫面上為空白的。

六、不要在畫面上顯示特定變數的內容 變數 mask

同樣的，有些變數的內容，無論在什麼環境，都不希望它完整的被呈現出來，如密碼欄位，這需求在 GitLab CI 上也可以設定，如下圖，在新增或修改變數時，可以選擇「Mask variable」，其就可以在輸出時不完整呈現。

如下簡單範例：

build-on-production:
  stage: build
  script:
    - echo "${ENV_ACCOUNT}"
    - echo "${ENV_PASSWD}"
  environment: Production

如下圖，在輸出變數 ENV_PASSWD 的位置，改為以「MASKED」呈現。

總結

在環境的設定上，除了可以透過 protected 設定某些變數僅能在 protected 分支或 Tags 上使用用來部署有機密性的環境外，目前在 GitLab 的付費版本上也提供了 Protected Environments 私密環境，用來指定僅有某些人或某些角色可以在該環境上部署。

我是墨嗓(陳佑竹)，期待這系列的文章能夠讓人有些幫助。